Dies ist der letzte Teil der Artikelserie „Mobile-Apps mit Delphi – eine Review über Möglichkeiten und Grenzen“. Hier demonstrieren wir praxisnah die Umsetzung einer kompletten Mobile-App und geben weiterführende Tipps für den Einsatz in realen Projekten.

Alternativen und Optionen

Es gibt folgende Alternativen zur vorgestellten Konfiguration:

• RAD Studio kann unmittelbar auf einem Windows-PC, d. h. ohne Virtualisierung ausgeführt werden. Der Zugriff auf einen iOS-Simulator kann dann über das lokale Netzwerk erfolgen. Ein Android-Emulator kann auf dem Windows-PC ausgeführt werden (x64-Architektur, langsam).

• Hilfsweise kann statt eines physischen Macs auch ein Cloud-Service genutzt werden. Auf diesem können dann Xcode und der Simulator installiert werden. Ein geeigneter Service ist beispielsweise [5]. Auf diesen Cloud-Computer wird in diesem Fall via Remote-Desktop zugegriffen. Ein physisches iPhone kann dann jedoch nicht zum Testen genutzt werden.

In jedem Fall gilt: Ab einem gewissen Fortschritt in der Entwicklung der Mobile-App muss diese regelmäßig auf physischen Geräten, d. h. Android-Smartphones und iPhones, getestet werden. Einige Features, wie beispielsweise die Sensibilität von Sensoren, lassen sich nur bedingt mit Hilfe von Emulation bzw. Simulation prüfen. Im Idealfall stehen in einem professionellen Entwickler-Set-up zum Testen mehrere Geräte mit unterschiedlicher Hard- und Softwareausstattung (Betriebssystemversionen) zur Verfügung.

Hinweis (bzw. eine ganz persönliche Anmerkung): Bitte lassen Sie sich bei der Konfiguration nicht frustrieren. Die Einrichtung der Developer-Pipeline für die Mobile-Entwicklung (Android, iOS) ist nicht trivial. Versionen und Tools müssen zueinander passen und die richtigen Befehle müssen auf der Kommandozeile eingegeben werden. Wenn man sich mit Konsole und Netzwerk nicht auskennt, ist es eine Herausforderung und es ist ganz normal, dass man einiges ausprobieren muss. Der Autor hat die Schritte zusammengestellt, um Android und iOS aus RAD Studio auf einer Maschine nutzbar zu machen. Das liest sich im Ergebnis einfach und logisch, doch der Weg bis zur Erkenntnis war bedeutend länger.

Mobile-Apps mit Delphi – Projektstart

Eine Mobile-Delphi-Anwendung startet man in der IDE typischerweise über Datei | Neu | Multi-Device-Anwendung (Abb. 9).

Es stehen verschiedene Projektvorlagen bereit (z. B. leere Anwendung oder Tabbed Template), die bereits eine Grundstruktur für Android und iOS enthalten. Die Projektgruppe enthält von Anfang an Einträge für beide Zielplattformen, und im Projektmanager kann man zwischen Android und iOS Device 64-bit (bzw. iOS Simulator, falls ein Apple Silicon Mac verfügbar ist) umschalten. Praktisch gesehen unterscheidet sich die Projektanlage kaum von einer VCL-Anwendung – abgesehen von der Auswahl eines FireMonkey-Projekts. Delphi legt eine Unit mit einer Formularklasse (einer Ableitung von TForm) an, die für Mobile-Apps üblicherweise zunächst die Namen Unit1.pas/Form1.fmx trägt. Darin befindet sich der gemeinsame Quelltext für beide Plattformen. Plattformspezifische Anpassungen kann man über Compilerdirektiven vornehmen (z. B. mit {IFDEF ANDROID} / {IFDEF IOS}). Soll beispielsweise unter iOS ein abweichender Programmablauf erfolgen, lässt sich das zur Not mit solchen Direktiven im Code lösen. Doch in vielen Fällen ist das gar nicht notwendig. Im Idealfall bleibt die Codebasis vollständig plattformneutral.

RAD Studio bietet viele abstrakte Klassen und Services, die Android und iOS vereinheitlichen – vom Dateisystemzugriff über HTTP-Anfragen bis hin zu Threading oder GUI-Komponenten. So kann man den Großteil der App-Logik ohne besondere Berücksichtigung des Ziel-OS entwickeln. Erst bei wirklich systemspezifischen Funktionen kommt man an einen Punkt, an dem man gezielt Code für eine Plattform schreiben muss.

Bevor die App erstmals gestartet wird, müssen einige Projekteinstellungen überprüft werden. Im Options-Dialog des Projekts wird der Application Identifier (Bundle-ID) festgelegt und es werden gegebenenfalls die benötigten Berechtigungen hinterlegt. So müssen für die Nutzung des Gerätestandorts (GPS) beispielsweise in Android die entsprechenden Berechtigungen (ACCESS_FINE_LOCATION etc.) aktiviert werden, damit Delphi sie in die Android-Manifest-Datei einträgt. Unter iOS wiederum muss sichergestellt werden, dass in der Datei Info.plist ein Eintrag für NSLocationWhenInUseUsageDescription vorhanden ist. Das kann ebenfalls über die Delphi-Projekteinstellungen konfiguriert werden. RAD Studio kümmert sich dann um die richtige Einbindung dieser Parameter ins Deployment. Für viele Standardfälle bringt Delphi bereits sinnvolle Voreinstellungen mit. Beispielsweise werden bei Verwendung der TCameraComponent automatisch die Kameraberechtigungen angefordert. Entwickler:innen behalten dennoch die Flexibilität, diese Einstellungen an ihre eigenen Erfordernisse anzupassen.

UI-Design mit FireMonkey

Die Benutzeroberfläche wird mit dem FireMonkey-Framework gestaltet, das einen grafischen Multi-Device-Designer (Abb. 10) bereitstellt.

Alle visuellen Komponenten, beispielsweise Buttons, Listen oder Eingabefelder, werden per Drag and Drop auf das Formular gezogen und dort ausgerichtet. Der Clou dabei ist, dass dieses eine Formular als Master-Form für alle Geräte dient. Das UI wird also einmal entworfen – und anschließend werden die gerätespezifischen Verfeinerungen vorgenommen, ohne dass der Code aufgespalten werden muss. Dabei erlaubt Delphi, sogenannte View-Varianten für unterschiedliche Auflösungen oder Formfaktoren anzulegen. So kann man beispielsweise eine spezielle iPhone-Ansicht definieren, in der bestimmte Elemente speziell angeordnet oder skaliert sind. Diese Varianten erben sämtliche Elemente und Logik von der Master-Form, lassen sich aber im Layout getrennt anpassen. In der Praxis bedeutet das: Ein Großteil des UI-Designs wird plattformübergreifend entworfen und nur dort nachjustiert, wo es nötig ist, beispielsweise bei größeren Bildschirmen, einem anderen Seitenverhältnis oder der Ausrichtung im Hoch- oder Querformat. Delphi bietet darüber hinaus eine Multi-Device-Vorschau an. Im Designer kann man sich das Formular parallel auf verschiedenen Gerätedummies anzeigen lassen, z. B. als iPhone 14 und als Android-Tablet. Das ist sehr hilfreich, um das responsive Design der Oberfläche früh zu überprüfen.

FireMonkey selbst setzt auf hardwarebeschleunigtes Rendering. Anders als die VCL (die auf nativen Windows-Controls basiert) zeichnet FMX sämtliche Steuerelemente selbst – plattformunabhängig und mittels GPU. Dadurch sind flüssige Animationen und aufwendige Grafikeffekte möglich, die von der Grafikkarte des Geräts profitieren. Standard-Controls wie Buttons oder Listboxen folgen dem Style-Prinzip, d. h. sie werden durch Style-Vorlagen dem jeweiligen Betriebssystem optisch nachempfunden. FMX bringt für Android und iOS eigene Style-Sets mit, sodass z. B. ein TSwitch-Schalter unter iOS wie ein nativer iOS-Umschalter aussieht. Über den Behavior Service passen sich zudem gewisse Verhaltensweisen automatisch an. So werden Tabs auf iOS am unteren Bildschirmrand, auf Android hingegen oben angezeigt.

Entwickler:innen können das Look and Feel auch vollständig selbst gestalten: Über den FMX Style Designer oder durch Zuweisung von alternativen Styles (Dark/Light Theme etc.) erhält man volle Kontrolle über die Optik. Auch plattformnative Controls lassen sich in FireMonkey einbinden.

Moderne FireMonkey-Oberflächen sind durch die GPU-Nutzung in der Regel sehr performant, allerdings erkauft durch einen initialen Overhead beim App-Start. Das Starten einer FMX-App dauert erfahrungsgemäß etwas länger als das Starten einer minimalistischen nativen App, da zunächst die FMX-Bibliothek geladen werden muss. In der Praxis bewegt sich das auf aktuellen Geräten jedoch im Rahmen von ein bis zwei Sekunden. Die Laufzeitperformance der Anwendung, beispielsweise beim Scrollen durch Listen, dem Öffnen von Formularen oder dem Durchführen von Berechnungen ist dagegen nahezu identisch mit der von nativen Apps, da der übersetzte Maschinencode ohne Zwischenschicht auf der CPU läuft. Durch die statische Verlinkung aller benötigten Bibliotheken liegt die App-Größe meist etwas über der von vergleichbaren nativen Apps. Angesichts heutiger Gerätespeicher ist das jedoch selten ein Problem. Insgesamt lässt sich festhalten, dass FireMonkey-UIs bei korrekter Verwendung hinreichend performant sind und den Nutzer:innen ein zeitgemäßes Nutzungserlebnis bieten.

Nutzung von Gerätesensoren

Eine Stärke von Delphi für Mobile ist der einfache Zugriff auf Gerätesensoren. Die RTL (Run Time Library) umfasst dafür vordefinierten Komponenten und Klassen, die die Sensorhardware abstrahieren. So gibt es beispielsweise eine Komponente TLocationSensor, die GPS-Geodaten liefert, einen TMotionSensor (für Beschleunigungssensor/Gyroskop), einen TOrientationSensor (Lagesensor/Kompass) sowie die TCameraComponent für den Zugriff auf die Kamera (Abb. 11).

Diese nicht visuellen Komponenten werden bei Bedarf auf das Formular gezogen. Anschließend kann dann über Ereignisse und Methoden auf die Sensordaten zugegriffen werden. Ein Beispiel: Durch Setzen von LocationSensor.Active := True startet die Standorterfassung. Über das Ereignis OnLocationChanged liefert die Komponente anschließend die aktuellen Breiten- und Längengrade, auf die im Code reagiert werden kann, beispielsweise um die Position auf einer Karte anzuzeigen.

Delphi kapselt hierbei die Unterschiede der Plattformen. Ob die Positionsdaten nun vom iOS-Dienst oder vom Android-Location-Provider stammen, braucht Entwickler:innen nicht zu kümmern. Ähnlich funktioniert TMotionSensor für Beschleunigungs- und Rotationsdaten, die beispielsweise zur Erkennung von Bewegungen oder zur Steuerung eines Spiels genutzt werden können. Auch auf die Gerätekamera kann mit wenig Aufwand zugegriffen werden. Die einfachste Methode stellt die Action TTakePhotoFromCameraAction dar: Platziert man diese Aktion und verknüpft sie mit einem Button, öffnet ein Tipp darauf direkt die native Kamera-App des Geräts, erlaubt das Aufnehmen eines Fotos und liefert das Bild anschließend zurück in die Delphi-Anwendung. Will man mehr Kontrolle, verwendet man die TCameraComponent. Diese bietet Funktionen, um die Kamera direkt im eigenen App-Fenster zu aktivieren, Fotos oder Videos aufzunehmen und z. B. zwischen Front- und Rückkamera umzuschalten. Einstellungen wie Auflösung oder Fokusmodus können ebenfalls gesetzt werden. So lassen sich umfangreiche Kamerafunktionen bis hin zu QR-Code-Scannern oder AR-Anwendungen realisieren, wobei für spezialisierte Anforderungen ggf. ein plattformspezifischer API-Aufruf nötig ist.

Neben GPS, Bewegungssensoren und Kamera unterstützt Delphi zahlreiche weitere Hardwarefeatures. Erwähnenswert ist die Bluetooth/BLE-Unterstützung: In RAD Studio gibt es also Komponenten sowohl für klassisches Bluetooth als auch für Bluetooth Low Energy.

Ein Aspekt, den es bei der Nutzung von Sensoren zu beachten gilt, sind die Berechtigungen. Wie zuvor erwähnt, müssen bestimmte Berechtigungen deklariert werden, wenn sie benötigt werden. Darüber hinaus erfordern neuere Android- und iOS-Versionen oft auch eine Bestätigung durch den Nutzer zur Laufzeit (Runtime Permission). Delphi stellt Hilfsfunktionen bereit, um diese Berechtigungen zur Laufzeit abzufragen und zu verarbeiten. Entwickler:innen sollten also beim ersten Zugriff auf Kamera, Mikrofon, Standort etc. überprüfen, ob die App bereits die entsprechende Freigabe hat. Falls dies nicht der Fall ist, sollte eine Anfrage an den User gestellt werden. Dies lässt sich mit wenigen Codezeilen umsetzen und entspricht dem Vorgehen in anderen Entwicklungsumgebungen.

Einbindung von System-APIs

Trotz des breiten Spektrums an vorkonfektionierten Komponenten kommt es in der Mobile-Entwicklung gelegentlich vor, dass eine sehr spezifische Plattformfunktion benötigt wird, sei es eine besondere Apple- oder Google-API, die (noch) nicht Teil von FireMonkey oder einer Drittanbieter-Bibliothek ist. Ein großer Vorteil von Delphi ist, dass man in solchen Fällen direkt auf die nativen APIs der Zielplattform zugreifen kann. Delphi bietet zu diesem Zweck sogenannte Bridge Units und Header-Übersetzungen an. Für iOS existieren in Delphi beispielsweise Namespaces wie iOSapi.Foundation oder iOSapi.UIKit, die die Objective-C-Klassen und -Funktionen des Apple SDK verfügbar machen. Darüber lassen sich beliebige iOS-Frameworks ansprechen, als würde man in Swift oder Objective-C programmieren.

Ein Beispiel: Möchte man Touch ID bzw. Face ID nutzen, kann man die entsprechenden Routinen aus Apples LocalAuthentication-Framework über Delphi aufrufen, entweder indem man die mitgelieferten Header-Übersetzungen verwendet oder indem man bei neueren APIs selbst Interfacedefinitionen schreibt. Ähnlich verhält es sich bei Android: Hierfür stellt Embarcadero den Java2OP-Converter bereit, der Java-Bibliotheken in Delphi-Code (Interfaceklassen) umwandelt. So kann man beispielsweise eine spezielle Android-SDK-Funktion nutzen, die nicht im FMX-Standardumfang enthalten ist, indem man die Java-Methode nach Delphi importiert. Delphi kompiliert im Hintergrund die entsprechenden JNI-Aufrufe, sodass die App zur Laufzeit die Android-JVM nutzen kann, um diese Funktionen auszuführen. Dieser Weg, direkt mit nativen APIs zu arbeiten, erfordert zwar etwas zusätzlichen Aufwand, gewährleistet aber, dass keine Funktionalität der Plattform unerreichbar bleibt.

In der Praxis gibt es dafür auch Communityunterstützung: Es stehen einige Open-Source-Projekte und Bibliotheken zur Verfügung, die gängige Mobile-Dienste kapseln und erweiterte System-APIs für Delphi bereitstellen.

Geeignete Use Cases und Grenzen

Es zeigt sich, dass Delphi (RAD Studio) im Jahr 2025 ein ausgereiftes Ökosystem für die Mobile-Entwicklung bietet. Die Stärken liegen vor allem in der Produktivität: schnelles visuelles Entwickeln, Wiederverwendung von Code und Komponenten sowie eine Codebasis für alle Plattformen. Diese Vorteile kommen insbesondere in folgenden Anwendungsfällen zum Tragen:

• Business- und Enterprise-Apps: Delphi eignet sich hervorragend, um datenbankgetriebene Anwendungen oder Unternehmenssoftware für mobile Endgeräte bereitzustellen. Bestehende Delphi-/VCL-Kenntnisse und -Code (z. B. Datenmodule mit FireDAC oder Logik aus einer Windows-Anwendung) lassen sich wiederverwenden, um eine passende Mobile-App als Ergänzung zu entwickeln. Wenn eine Firma bereits über eine umfangreiche Delphi-Codebasis verfügt, ist der Schritt zu Android-/iOS-Apps effizient umzusetzen.

• Cross-Plattform-Projekte mit knapper Timeline: Wenn man „schnell“ eine App für Android und iOS gleichzeitig benötigt, ermöglichen die RAD-Prinzipien von Delphi ein rasches Vorgehen. Mit einem kleinen Team erreicht man Ergebnisse, für die man nativ eventuell zwei Teams bräuchte. Gerade Prototypen für Start-ups oder Pilotprojekte können so in kurzer Zeit umgesetzt werden, ohne dass man sich von Beginn an auf eine Plattform festlegen muss.

• Industrie und spezialisierte Hardware: In Fällen, in denen Geräte mit besonderer Hardware angesteuert werden, etwa Barcodescanner, Messgeräte oder Spezialsensoren auf Android-Geräten, fällt Delphis Nähe zur Hardware besonders ins Gewicht. Man kann native Bibliotheken der Hardwarehersteller einbinden und hat volle Kontrolle über serielle Schnittstellen, Bluetooth-Protokolle usw. – und das alles in Delphi, ohne auf C++ oder Java wechseln zu müssen.

• Multi-Platform-Desktop-Mobile-Kombinationsprojekte: Wenn eine Anwendung nicht nur auf Mobile-Geräten, sondern auch auf Windows-, macOS- und Linux-Desktops laufen soll, bietet Delphi den Vorteil, dass FireMonkey auch Desktopplattformen bedienen kann. Weite Teile der Codebasis können für Desktop und Mobile gemeinsam genutzt werden, es müssen nur das UI und Details angepasst werden. Diese „Write once, compile everywhere“-Fähigkeit ist ein Leistungsmerkmal.

Selbstverständlich gibt es auch Grenzen und Szenarien, in denen Delphi weniger geeignet ist. Grafikintensive Spiele etwa werden meist in spezialisierten Engines (Unreal, Unity etc.) entwickelt. Zwar unterstützt Delphi 2D-/3D-Grafik mit FMX, die Developer-Community in diesem Bereich ist jedoch kleiner. Anwendungen, die zu 100 Prozent an die nativen UI-Richtlinien einer Plattform angepasst sein müssen, können mit Delphi zwar umgesetzt werden, erfordern aber mitunter zusätzlichen Feinschliff beim Styling, damit sie pixelgenau wie eine typische iOS- oder Android-App aussehen. Wenn das oberste Ziel darin besteht, dass niemand einen Unterschied zu den Apple Human Interface Guidelines oder zum Material Design erkennen kann, muss man in der Delphi-Entwicklung bewusst mit Styles und gegebenenfalls mit nativen Controls arbeiten.

Ein weiterer Punkt sind externe Frameworks und Ökosystemabhängigkeiten. Für Android und iOS existiert eine Fülle an Open-Source-Bibliotheken, deren Direktverwendung in Delphi jedoch nicht immer trivial ist. Zwar lassen sich nichtvisuelle Bibliotheken meist problemlos einbinden, doch bei komplexen UI-Komponenten oder plattformspezifischen Cloud-SDKs kann die Integration aufwendiger werden.

Auch das Tooling rund um die App (Build-Pipelines, CI/CD, UI-Testautomation) ist für Delphi weniger standardisiert verfügbar als für Xcode bzw. Android Studio. Eine Rolle spielen dabei nicht zuletzt der Kostenfaktor und die strategische Ausrichtung: RAD Studio ist ein kommerzielles Produkt und auf dem Markt gibt es weniger Entwickler:innen für Delphi Mobile als für die großen Plattformsprachen. Für lange Projektlaufzeiten und sehr große Teams kann das ein Kriterium sein.

Praxisbeispiel

Nun zeigen wir, wie eine Mobile-App mit Delphi und FireMonkey entwickelt werden kann. Am Beispiel wird praxisnah demonstriert, wie die typischen Anforderungen einer Mobile-App – Zugriff auf Kamera, Sensoren, lokale Datenhaltung und UI-Darstellung – mit Delphi umgesetzt werden können. Die App soll die folgenden Kernfunktionen bereitstellen:

• Fotoaufnahme direkt über die integrierte Kamera oder das System-Kamera-Interface,

• Geodatenerfassung zum Zeitpunkt der Aufnahme,

• Zusatznotizen pro Bild zur kontextuellen Dokumentation,

• Speicherung der Metadaten lokal auf dem mobilen Device,

• Galerieansicht, in der alle Fotos mit Miniaturansicht, Aufnahmezeit und Standortinformationen gelistet werden,

• ggf. Detailansicht und Teilen-Funktion, um Bilder samt Metadaten über die native Share-Sheet-Funktion des Betriebssystems weiterzugeben.

Einen ersten Eindruck vom geplanten Vorhaben liefert der folgende Prototyp (Abb. 12).

Sehen wir uns wesentliche Schritte der Umsetzung an:

1. Man kann beispielsweise die Vorlage Geräteübergreifende Anwendung mit Kopf- und Fußzeile auf der Basis von FireMonkey wählen. So erhält man ein Grundgerüst zur Gestaltung des User Interfaces auf mobilen Geräten.

2. Gestalten wir nun das User Interface des Hauptformulars: Dazu platzieren wir eine Kopf- und eine Fußzeile (TToolBar) sowie einen Layoutcontainer, der den restlichen Platz für die Medienliste (Content) einnimmt.

3. Als dynamische Liste verwenden wir eine TListView-Komponente. Diese können wir individuell gestalten, d. h., wir können festlegen, wie die einzelnen Listenelemente angezeigt werden.

4. Für die Datenhaltung definieren wir eine Klasse TPhoto, die die Daten zu den Bildern, Orten und Merkmalswerten verwaltet. Die Liste der Objekte wird in einem Datentyp nach dem Schema FPhotos: TObjectList<TPhoto> gespeichert.

5. Zum Aufnehmen von Bildern mit der Kamera bietet RAD Studio die Schnittstelle FMX.MediaLibrary.IFMXCameraService. Mit Hilfe dieser Schnittstelle kann die Kamera plattformübergreifend auf iOS und Android genutzt werden [6]. Denken Sie daran, die entsprechenden Berechtigungen für die Plattformen gemäß Dokumentation zu setzen.

6. Zur Ermittlung des Standorts steht die Komponente System.Sensors.Components.TLocationSensor zur Verfügung. Sie kapselt den Zugriff auf die Ortungsdienste für die Zielsysteme [7]. Auch hier sind Berechtigungen in den Projekteigenschaften erforderlich.

7. Die Datenspeicherung auf dem mobilen Device kann in einer lokalen SQLite-Datenbank erfolgen. Dazu wird aus Delphi die FireDAC-Bibliothek genutzt [8].

Mit diesen Schritten ist das grundsätzliche Vorgehen zur Programmierung unserer Beispiel-App für Android und iOS skizziert. Einen ersten Eindruck von der App auf iOS und Android vermitteln Abbildung 13 und 14.

Während der laufenden Entwicklung ist es oft sinnvoll, die Funktionsweise schnell zu überprüfen. Das kann in vielen Fällen dadurch geschehen, dass man die App direkt als Windows-Applikation ausführt. Dank der Cross-Platform-Fähigkeit ist das kein Problem.

Fazit

Im Jahr 2025 eignet sich Delphi für geschäftliche Apps, Prototypen und alle Projekte, bei denen eine schnelle Entwicklung für mehrere Plattformen gefragt ist und die volle native Performance wichtig ist. Die Möglichkeiten reichen von klassischen Formular- und Datenbank-Apps über multimediale Anwendungen bis hin zu IoT-nahen Lösungen mit Sensorintegration. Die Grenzen liegen vor allem dort, wo extreme Plattformtreue im UI oder die maximale Nutzung des jeweiligen nativen Ökosystems verlangt wird – in diesen Fällen kann Delphi zwar mithalten, es ist jedoch mehr Handarbeit erforderlich. Für viele Anwendungen im üblichen Rahmen bietet Delphi jedoch einen ausgewogenen Kompromiss aus Entwicklungstempo, Codeeffizienz und Anwendungsleistung, wodurch es zu einer attraktiven Option für Mobile-Entwickler:innen wird.

Frequently Asked Questions (FAQ)

1. Wofür eignet sich Delphi 2025 in der Mobile-Entwicklung?
   Delphi eignet sich insbesondere für geschäftliche Apps, Prototypen und Cross-Plattform-Projekte, bei denen schnelle Entwicklung und native Performance gefragt sind. Es unterstützt Android, iOS und in Kombination auch Desktop-Plattformen.
2. Wie startet man ein Mobile-Projekt in Delphi?
   Ein Mobile-Projekt wird in der IDE über „Datei | Neu | Multi-Device-Anwendung“ angelegt. Vorlagen wie leere Anwendungen oder Tabbed Templates liefern eine Grundstruktur für Android und iOS.
3. Wie wird das User Interface mit FireMonkey gestaltet?
   Die UI wird im grafischen Multi-Device-Designer per Drag-and-Drop erstellt. Master-Formulare dienen allen Geräten, während View-Varianten für unterschiedliche Auflösungen und Formfaktoren nachjustiert werden können.
4. Wie erfolgt der Zugriff auf Gerätesensoren?
   Delphi stellt Komponenten wie TLocationSensor, TMotionSensor, TOrientationSensor und TCameraComponent bereit. Diese abstrahieren die Plattformunterschiede und erlauben den Zugriff auf GPS, Bewegungssensoren, Kamera und weitere Hardware.
5. Welche Berechtigungen müssen Entwickler berücksichtigen?
   Für Sensoren wie Kamera, GPS oder Mikrofon müssen Berechtigungen in den Projekteinstellungen hinterlegt werden. Neuere Android- und iOS-Versionen erfordern zusätzlich Runtime Permissions, die Delphi unterstützt.
6. Kann Delphi auf plattformspezifische APIs zugreifen?
   Ja, über Bridge Units, Header-Übersetzungen und Namespaces wie iOSapi.Foundation oder Java2OP können native Funktionen direkt genutzt werden. So lassen sich Apple- oder Android-spezifische Features in Delphi einbinden.
7. Welche Projektarten profitieren besonders von Delphi?
   Delphi eignet sich für Business- und Enterprise-Apps, Cross-Plattform-Projekte mit knapper Timeline, Industrieanwendungen mit spezieller Hardware und Multi-Platform-Desktop-Mobile-Kombinationsprojekte.
8. Wo liegen die Grenzen von Delphi in der Mobile-Entwicklung?
   Delphi ist weniger geeignet für grafikintensive Spiele, extrem plattformtreue UI-Anforderungen oder komplexe Drittanbieter-Frameworks. Auch das Tooling und die Community sind im Vergleich zu Xcode oder Android Studio begrenzter.

Links & Literatur

[1] https://www.embarcadero.com/products/rad-studio/whats-new-in-12-athens

[2] https://docwiki.embarcadero.com/RADStudio/Athens/en/Running_Your_iOS_Application_on_the_iOS_Simulator

[3] https://www.embarcadero.com/starthere/xe7/mobdevsetup/android/en/running_your_android_application_on_an_android_emulator.html

[4] https://docwiki.embarcadero.com/RADStudio/Athens/de/Installieren_des_Platform_Assistant_auf_dem_Mac.

[5] https://www.macincloud.com

[6] https://docwiki.embarcadero.com/RADStudio/Athens/en/Taking_Pictures_Using_FireMonkey_Interfaces

[7] https://docwiki.embarcadero.com/RADStudio/Sydney/en/Mobile_Tutorial:_Using_Location_Sensors_(iOS_and_Android)

[8] https://docwiki.embarcadero.com/RADStudio/Sydney/de/Mobile-Tutorial:_Verwenden_von_FireDAC_in_mobilen_Anwendungen_(iOS_und_Android)

[9] https://github.com/veikkoEF/PhotoAndLocation/settings

[10] https://entwickler-konferenz.de/bootcamp-delphi-cross-platform-entwicklung-fuer-ios-und-android